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ABSTRACT 



The objective of this thesis is to analyze the fleet mix planning problem, 
develop an approach to evaluate alternative fleet mixes, and implement the 
approach in a decision support system (DSS). In particular, this research is 
conducted in the context of the acquisition of a mix of patrol boats to replace 
the aging Point Class patrol boats within the U. S. Coast Guard. The analysis 
of an alternative fleet mix involves, among other things, the evaluation of 
cost, activity and performance measures for that fleet mix. Several analytic 
and forecasting models are used to determine costs and activity measures for 
various fleet mixes, and simulation games are played to assess expected 
mission performance for each mix under a set of mission scenarios. A rule- 
based deductive model is employed to determine and score the response of a 
given fleet mix to events occurring during the simulation. These models are 
implemented and integrated in a decision support system which combines 
the mathematical models with a database system, an expert system, and user 
interface tools. It is hoped that repeated use of the system, analysis of the 
alternative fleet mixes using a large number of data sets, and post-evaluation 
analysis and explanations, will help provide the decision-maker insight in to 
the problem, and will facilitate a judicious decision. 
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I. INTRODUCTION 



This research examines and analyzes the fleet mix planning problem, 
develops a simulation approach to evaluate the performance of alternative 
fleet mixes, and implements this method in a decision support system (DSS). 
Further, we present and apply our solution approach for fleet mix planning 
in the context of patrol boat acquisition within the United States Coast Guard 
(USCG). The DSS presents evaluation results for alternative fleet mixes, 
allowing a decision maker the ability to make comparisons and decisions. 
The system is being used by the USCG which provided us with an ideal 
application within the Patrol Boat Capability Replacement Project office. 

A. BACKGROUND 

Fleet mix planning is an important issue within many organizations 
including rental vehicle companies, the U.S. Navy and the U. S. Coast Guard. 
This section provides an overview of the fleet mix problem with specific 
references to the Coast Guard patrol boat fleet mix. 

1. Fleet Mix 

Broadly defined, a fleet mix is a combination of various assets. Within 
our scope a fleet mix is defined as a combination of various vessels, assigned 
to specific homeports, that have been selected to maximize performance or 
minimize costs while meeting the requirements of the assigned mission. An 
example of a fleet mix is a nationwide car rental agency. The agency operates 
in an industry where having the right mix of cars is crucial to competing with 
other agencies. The similarities between a car rental agency and the Coast 
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Guard are limited, but worth a brief comparison. Both are required to provide 
the proper mix of assets to their selected locations. Both also schedule 
maintenance periods for assets while still meeting their mission objectives. 
In addition, both must have rapid availability on short notice. 

2. Patrol Boat Fleet Mix 

The Coast Guard has traditionally called its vessels cutters and 
distinguished those that are 80 to 120 feet in length by referring to them as 
patrol boat cutters [Ref. l:p. 14]. The Coast Guard currently has approximately 
100 patrol boats that operate in eight coastal districts throughout the United 
States, including Hawaii and Alaska. The patrol boat fleet consists mainly of 
boats in two classes: the Point class and the Island class. The primary mission 
requirements of the patrol boat fleet are enforcement of law and treaties 1 
(ELT), search and rescue (SAR), and defense operations [Ref. l:p. 14]. 
Secondary missions are marine environmental protection (MEP), marine 
safety and aids to navigation. 

3. Replacing the Point Class Patrol Boat 

The Point Class patrol boats are approaching the end of their useful 
service life. The Coast Guard is planning to retire the aging Point class patrol 
boats gradually during the decade of the 1990's [Ref. 2:p. 1-1]. The Patrol Boat 
Capability Replacement Project office is studying candidate replacement 
cutters that can fulfill mission requirements and have better performance 
than its predecessor. 



^rug interdiction is a highly visible mission and a part of ELT. 
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4. Candidate Replacement Cutters 

There are three candidate replacement cutters being considered by the 
Patrol Boat Capability Replacement Project office. The first is the Island class 
patrol boat that has a length of 110 feet. This patrol boat class has been in 
service since 1983 and is still being built for the Coast Guard. The Coast Guard 
plans to acquire 47 of these patrol boats. The second candidate is the Heritage 
class patrol boat that has a length of 120 feet. This cutter was designed by the 
Coast Guard Naval Engineering division for improved stability and 
endurance over previously designed patrol boats [Ref. 2: p. 2-14]. The 
prototype ship is expected to be completed in 1992. The third candidate 
replacement cutter is the notional design patrol boat. Initial design studies are 
still in progress. Preliminary design objectives for the vessel include a 
shallow draft with a length of 75 to 85 ft. 

5. Reasons for a Mixed fleet 

Each candidate replacement class has certain advantages and 
disadvantages when compared to the other classes [Ref. 2]. For example, the 80 
foot Notional design craft would require fewer crew (therefore, lower 
personnel costs), would be more fuel efficient at a given speed, and would 
have a shallower draft than either the Heritage or Island class patrol boats. 
These benefits could be significant if the mission requirement was primarily 
SAR, where a small, nimble and shallow draft vessel could maneuver near 
shoal water. 

However, the Notional design would have a lesser endurance of three 
days compared to five or seven days for the other two candidate patrol boats. 
The vessel would be less stable in heavy seas. With a smaller crew, the 
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notional design would also have difficulty supplying a four or five member 
boarding party 2 . These limitations would hinder the Notional patrol boat as a 
drug interdiction vessel, where endurance and boarding parties are important 
factors. 

Utilizing a mixed patrol boat fleet gives the Coast Guard a higher 
flexibility in accomplishing its mission objectives. Limiting replacement of 
the Point class patrol boat to one class of vessels would restrict selection 
opportunities. The tradeoffs between various kinds of vessels and the need to 
diversify the fleet are important considerations. A decision to improve the 
capability of the fleet in one evaluation category will most often result in a 
tradeoff or degradation in another category. For example, patrol boats could 
be designed with larger fuel tanks and more bunks for watchstanders, to 
provide an increased endurance at sea. The tradeoff is that the cost of the 
vessel would increase, and maximum speed of the patrol boat would likely be 
reduced for a given engine horsepower. Similarly, a decision to reduce the 
costs in one category (acquisition cost) will most often require a higher cost in 
another area (maintenance costs) or may cause degradation in a capability 
(lower maximum speed). 

6. Complexity of Fleet Mix Planning 

Many factors must be considered when selecting a fleet mix. A new 
fleet is not restricted to being uniform with respect to type, size, or 
configuration of vessel. Figure 1 illustrates the complexity of the replacement 



2 A boarding party is used to inspect other vessels for compliance with U. 
S. laws and treaties. A small boat is sent from the patrol boat to the other 
vessel. Five personnel are normally needed for this operation. 
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process. The Patrol Boat Capability Replacement Project office must contend 
with all of these factors. These complex factors are individually presented in 
Chapter n. Simply stated, the task is to determine a fleet mix for a given time 
frame, that will fulfill mission requirements, and any new unknown 
requirements, given that only X number of boats can be built per year, and 
that the decision is restricted by a congressionally mandated budget. The 
decision makers must consider the relative advantages and disadvantages of 
the alternative fleet mixes. 
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Figure 1-1 Complexity Issues of the Replacement Process. 



B. RESEARCH OBJECTIVES 

The objectives of this thesis are 1) to propose a method for addressing fleet 
mix planning, and 2) to design a prototype DSS that will support the specific 
application in patrol boat acquisition. The four primary research questions 
that are guiding this thesis are: 
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• What information should the DSS provide to facilitate judicious fleet 
mix decision making? 

• What information presentation approach should be used to provide the 
user easy access to concise information? 

• What factors, attributes, or characteristics of a fleet mix are relevant in 
making relative comparisons between alternatives? 

• What factors are relevant in justifying the results obtained from a fleet 
mix alternative? 

C PROPOSED SOLUTION 

Our goal has been to develop a prototype DSS that would be immediately 
useful and would help a decision maker select a better fleet mix alternative. 
This paper presents an approach to fleet mix planning that 1) assists decision 
makers in developing and comparing arguments regarding alternative 
courses of action, 2) presents the attribute measures in an accessible and easy 
to understand format, and 3) provides a DSS that will be immediately useful 
to solve part of the fleet mix problem [Ref. 3:p. 11-14]. 

D. SCOPE 

The focus of this research is on the acquisition of patrol boats in the Coast 
Guard, one aspect of the broader fleet mix planning process. The research will 
design and develop a prototype DSS that will allow Coast Guard planners to: 



• select patrol boats for the fleet mix alternative. Options will include the 
82 ft. Point class 3 (WPB 82), the 110 ft. Island class (WPB 110), the 120 ft. 
Heritage class (WPB 120), and the Notional design patrol boat (WPB 80). 
The user can modify any characteristics of the above patrol boats. 
Additional DSS features allow new patrol boat classes to be defined by 
the user. 



3 Though the Point class patrol boats will be retired soon, the class is 
included to provide the baseline fleet mix. 
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• define or modify homeport assignment of each patrol boat within a fleet 
mix. 

• compose multiple fleet mix alternatives. 

• evaluate fleet mix alternatives on the basis of cost, activity, and 
performance measures. 

For demonstration purposes, we will evaluate three fleet mix alternatives 
proposed by the Coast Guard. The selected fleet mixes are: a fleet mix 
consisting of the present mix of patrol boats 4 , and two hypothetical fleet mix 
alternatives. The present fleet mix will serve as a baseline for comparison 
studies. 

The research will not: 

• evaluate helicopters and other airborne Coast Guard assets. 

• evaluate other missions of the USCG (i.e. buoy tending and polar 
operations) 

• provide an absolute value of fleet mix performance. The DSS will 
provide relative performance measures that can be compared to other 
fleet mix alternatives. 

• rank order fleet mix alternatives. Instead the decision maker compares 
the evaluation results, assigns his own relative weight to the displayed 
performance measures, and selects the better fleet mix alternative. 

E. THESIS ORGANIZATION 

Chapter II discusses the fleet mix planning problem and presents an 
alternative solution approach to the problem. Chapter III presents the fleet 
mix DSS design and introduces our functional approach. Chapter IV discuses 
the implementation of the fleet mix DSS. Fleet Mix analysis is discused in 
Chapter V. In Chapter VI we summarize the findings and propose ideas for 
further research. 



4 The baseline fleet mix uses the patrol boats operating on January 1, 1991. 
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II. THE FLEET MIX DECISION MODEL 



This chapter provides an overview of the fleet mix decision environment as it 
relates to patrol boat replacement in the U. S. Coast Guard. It also introduces our 
approach for decision making in this context. The first section describes the fleet 
mix planning problem. The second section discusses various stages in the fleet 
mix decision process. The third section discusses alternative approaches for 
solving fleet mix problems. The last section presents an overview of our solution 
approach. 

A. THE FLEET MIX PLANNING PROBLEM 

The patrol boat fleet mix planning problem is complex and has been a major 
consideration of the Coast Guard's Patrol Boat Capability Replacement 
Acquisition project. New patrol boats are needed during the 1990's to replace the 
Point class patrol boats. The following questions are typical of the questions 
facing the Patrol boat planners. How many patrol boats are needed to meet the 
mission requirements? What types of patrol boats are most cost effective in the 
fleet mix? How many of each type should be purchased? Where should the 
patrol boats be located to best fulfill the mission requirements? 

We analyze the fleet mix planning problem by considering the following 
aspects in this section: uncertainty, objectives and constraints, evaluation criteria, 
variables, and information requirements. 

1. Uncertainty 

The planning of a fleet mix is complicated by various kinds of uncertainty. 
There is uncertainty about the type of activities that will be assigned to patrol 
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boats in the future [Ref. 3:p. 14]. As stated in Chapter I, the primary mission 
areas for patrol boats are currently SAR and drug interdiction (ELT). The SAR 
mission may be assigned to patrol boats, helicopters, fixed wing aircraft or other 
Coast Guard vessels, depending on the nature of the incident, the location of the 
incident and assets available for response. The drug interdiction mission is 
currently assigned to patrol boats, aircraft, aerostats, and other sensors and assets 
outside the Coast Guard. In the future, the mission emphasis for patrol boats 
may change. For example the Coast Guard may not be involved in towing 
vessels to port, but instead would arrange to have disabled vessels towed to port 
by a private rescue company hired by the boat owner. 

There is uncertainty about the future demand for Coast Guard patrol boat 
response. The demand for a given day is the number of boating accidents or 
drug activity in the coastal waters that require patrol boat response. The 
geographic distribution (location) of future activity is also unknown. For 
example, the information about where incidents will occur, when they will occur 
and the type of response required by the Coast Guard is difficult to predict, even 
in terms of probability distributions. Fundamental changes in our society, such 
as changes in boating patterns, a dramatic rise in fuel prices or elimination of 
illicit drug use could affect the demand for patrol boats. 

2. Patrol Boat Fleet Mix Objectives and Constraints 

The Coast Guard patrol boat capability replacement project prepared a 
Mission Needs Statement in 1983 for the patrol boat replacement study. A partial 
listing is presented below. The patrol boat replacement "must possess the 
capability to: 

Perform multi-mission patrols in coastal waters with an endurance of 
approximately five days. 



9 



Intercept, overtake and maintain hot pursuit of waterborne craft normally 
used for illicit operations. 

Provide a five person custody crew to sail a seized vessel up to 24 hours 
while escorting the vessel and the custody crew. 

Carry out all described activities in 10-foot high sea conditions, and be able 
to operate at a reduced performance level in 25-foot seas and 60 knot 
winds." [ Ref. 4:p. 4] 

Constraints on the fleet mix planning problem limit the range of solution 

possibilities. Following is a brief look at the constraints imposed: 

• Budget. Proposed budgets for all aspects of patrol boat acquisition, 
operations, maintenance and retirement must be approved by Congress. 

• Personnel. The number of personnel available to crew patrol boats. A 
solution that requires more boats than can be operated by the available 
personnel would be infeasible. 

• Geography. The Coast Guard has selected certain ports as patrol boat 
homeports. Each port has a limited pier size, a limited turning basin (for 
maneuvering patrol boats near the pier) and limited water depth in the sea 
access channel. Although new homeports can be developed and access 
channels can be dredged, the additional expenses incurred must be 
considered in the process. 

• Vessel Capabilities. Once the vessel is designed and built, attempts to 
improve sea keeping, maximum speed, or attempts to change the vessel 
draft are difficult and expensive. 

3. Measurement Criteria 

The fleet mix decision support system will facilitate the comparison of 
alternative fleet mixes. The relative advantage of one fleet mix alternative over 
the others is determined by comparing the various measures for each fleet mix. 
We define three types of measures to evaluate a fleet mix. These are measures of 
mission performance, potential activity (capability), and costs. 

Performance measures indicate how well a fleet might accomplish its 
mission. The measures include the number of successful missions, the average 
time required to reach the scene of a SAR case and the number of failed missions. 
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Activity measures show the portion of time used (or available) for each of the 
patrol boat's tasks. These measures include patrol hours and maintenance hours. 
Cost measures capture the cost of using resources by the patrol boats within the 
fleet mix. Examples include personnel costs for boat crews, operating costs and 
acquisition cost. 

4. Variables 

Analysis of a fleet mix involves the study of important variables and 
problem characteristics. Consultation with the Coast Guard patrol boat 
replacement project and other Coast Guard experts provided insight on the 
selection of variables. Additionally, variables were selected if they had an impact 
on at least one of the measures. 

Variables in a decision model are either controllable, uncontrollable or 
outcome variables [Ref. 5:p. 106]. Those variables that the decision maker has 
measurable effect on are called controllable variables. The decision maker selects 
values for these variables. An example is homeport assignment for each patrol 
boat in the fleet mix. Uncontrollable variables are not under the control of the 
decision maker. Uncontrollable variables in the fleet mix problem include 
weather conditions, the number of drug boats attempting to enter a port and the 
number of SAR cases that will occur. Outcome variables or decision variables are 
the results of a decision model. The decision model performs an evaluation 
based on the values of the controllable variables and estimated values for the 
uncontrollable variables to produce an outcome variable. 

5. Data Sources 

The quality and availability of data affect the quality and reliability of the 
analysis. Two categories of historical data are important when analyzing the 
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fleet mix. One category is the patrol boat operational data. This class includes the 
percentage of time spent on each mission objective, and each aspect of the costs 
involved in operating a patrol boat for a year. Operational data has been 
collected by the Coast Guard to support various decisions in the patrol boat 
acquisition process. The second category is the environmental data. This class 
includes data about incidents and illicit operations that occur within the Coast 
Guard's area of responsibility. The Coast Guard maintains databases to collect, 
sort and retrieve data about SAR cases and law enforcement cases (which include 
ELT). Details about unreported accidents and illicit activity are obviously not 
available. 

B. THE FLEET MIX DECISION PROCESS 

The fleet mix planning problem encompasses a broad range of decisions from 
the initial acquisition through disposal of the retired hull. The focus in this 
research is on the acquisition of patrol boats. The acquisition decision needs to 
be justified to the Department of Transportation and Congress. Factors outside 
the Coast Guard may affect the fleet mix selected. These aspects of the fleet mix 
decision process are discussed below. 

1. Decision Lifecycle. 

7 

Replacement of patrol boats requires several major steps. The Office of 
Management and Budget has defined a process that must be followed when 
acquiring new major systems, including a new class of patrol boats. The A-109 
Circular (1977) requires that the responsible office (USCG) establish mission 
needs and operational requirements for the new system (patrol boats). The first 
four milestones and three phases of the process are summarized below [Ref. 6:p. 
1-2]. 
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• Milestone 0: The Coast Guard determines if an identified mission warrants 
the study of alternative concepts. Identify the minimum set of alternative 
concepts. 

• Phase I: This is the Concept Exploration and Definition Phase where 
various alternatives are explored for meeting the mission needs, and the 
most promising concept is identified. 

• Milestone I: The Coast Guard determines if the results of Phase I warrant 
establishing a new acquisition program. 

• Phase II: This is the Demonstration and Validation phase. Objectives of 
this phase include proving the capability of the preferred system by 
developing a prototype and developing analysis for supporting the 
Milestone II decision. 

• Milestone II: The Coast Guard determines if phase II warrants continuation, 
and if so, establishes a development baseline containing program cost, 
schedule and performance objectives and acceptable variances. 

• Phase III : The objectives of Phase m are to develop a stable ship design, 
and demonstrate through testing that the system capabilities can be attained 
and meet the mission need. 

• Milestone HI : This is Production Approval. The Coast Guard determines if 
Phase III warrants continuation and if so, establishes a production baseline. 

The fleet mix decision lifecycle also includes decisions about homeport 

assignment, timing of mid-life maintenance to the patrol boats and retirement of 

patrol boats. Since acquisition is the current concern of the patrol boat 

replacement project, this research will focus on the acquisition process. 

2. Justification of the Decision. 

Each decision in the acquisition process is reviewed based on the 
justification and supporting evidence provided by the responsible office (patrol 
boat replacement project). With tight federal budgets, only those programs that 
are presented as meeting a real need and are cost effective will be approved. 
Weak justification and lack of supporting evidence for a proposed acquisition 
would reduce the probability of the acquisition being authorized by Congress. 
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Therefore to be useful, a decision support system must have features to provide 
supporting evidence and justification for decisions. 

3. Other Factors Affecting the Fleet Mix Decision. 

The political nature of the congressional appropriation process is an 
unknown factor in the fleet mix decision. The decisions regarding patrol boat 
construction and location of homeports will ultimately be approved, modified or 
rejected by Congress. Their decisions may not reflect the depth of evidence 
supporting one alternative over another. 

C ALTERNATIVE SOLUTION APPROACHES 

There is no existing integrated set of models that provides analysis for the 
whole planning problem. At least a small set of models of the Coast Guard's 
patrol boat operation is necessary to evaluate and compare fleet mix alternatives. 
One alternative fleet mix approach is presented below. 

1. The Balance Sheet Approach 

[Ref. 3] states that the fleet mix problem is conceptually an optimization 
problem with multiple objectives in an uncertain environment. The authors 
point out practical problems with a single large, complex, multiobjective 
stochastic model. They used a DSS approach to solving the fleet mix problem 
[Ref. 3:p. 11]. The DSS was designed to help decision makers in developing and 
comparing arguments regarding alternative courses of action. In the balance 
sheet concept, a list of key fleet attributes that can be measured is developed. 
The list is presented in an accessible, easy-to-explore manner in the DSS. Seven 
attributes were chosen to represent the comparison of fleets: the annualized cost 
of a fleet, a performance index, a flexibility index, a fleet quality index, the 
number of aircraft, the number of major ships and the number of at-sea officer 
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billets. Three of the attributes need a brief explanation. The performance index 
is the "value of a multiattribute utility model that accumulates measures of 
effectiveness values across all major assets in the fleet" [Ref. 3:p. 13]. The fleet 
quality describes how worn out the fleet is. The flexibility index measures the 
range of assets available in the fleet. 

The DSS was designed for the Coast Guard in the general area of fleet mix 
planning. The authors indicate that their prototype DSS has met with some 
initial success. 

D. FLEET MIX MODELS 

In the past, the Coast Guard has used two models for specific aspects of fleet 
mix planning. The first predicts the performance of a vessel on patrol. The other 
model evaluates the performance of vessels in a SAR simulation. 

1. Patrol Boat Performance. 

"Predicting Patrol Performance" [Ref. 7] presents an approach using a 
Markov model for predicting the performance of a vessel of patrol. The author 
presents a classification of the patrol activities of a vessel and a list of 
characteristics important for modeling patrol boat capabilities. 

2. SAR Simulation 

The "Search and Rescue Monte Carlo Simulation" [Ref 8:p. 15] uses a 
simulation approach to measure the effectiveness of various types of proposed 
patrol boat designs in a SAR situation. The authors include salient aspects of a 
typical SAR case (distance to datum, search, survival time and weather) in their 
model. 
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E. SOLUTION APPROACH 

Having defined the problems in fleet mix planning, we present an overview 
of our approach here and discuss it in more detail in Chapter HI. The DSS will 
assist decision makers in developing and comparing arguments regarding 
alternative courses of action. The fleet mix alternatives selected by the user are 
evaluated by the DSS in the attributes of cost, potential activity and performance. 
Evaluation results for all fleet mix alternatives are presented in a common table, 
allowing the user to detect advantages and disadvantages of one fleet mix 
alternative relative to the others. 

The performance measures for a fleet mix alternative will be produced using 
a computer simulation. A computer simulation is used to simulate a real world 
event or a set of events, under a controlled set of rules, and executes a series of 
actions that are then measured for comparison [Ref. 5:p. 108]. Specifically, we 
simulate a fleet of patrol boats, operating within a designated boundary (namely 
a Coast Guard district), and measure the performance using a set of randomly 
generated events. For example, one of the randomly generated events is a SAR 
case. A Coast Guard cutter will need to respond. A cutter will be selected, and 
set on course to commence search and rescue assistance. Appropriate 
characteristics of the cutter and the event will be measured. Example of these 
characteristics are: "time the victim is in water" and "the fuel consumed by the 
patrol boat". This process continues with random events and responding patrol 
boats during a simulated 168 hour week. The significant measures are totaled. 
The Coast Guard decision makers can use these measures to compare alternative 
fleet mixes. Our DSS will not produce an optimal fleet mix, yet it will provide 
the user with valuable information for comparing alternatives. 
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This chapter has presented a view of the complexity of the fleet mix planning 
problem and some of the factors that are considered in the decision process. One 
alternative solution approach to the fleet mix planning problem, and two Coast 
Guard patrol boat performance evaluation tools were discussed. This research 
builds on the previous research, and presents our DSS for fleet mix planning. 
Chapter III will discuss our design for the patrol boat fleet mix planning DSS. 
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III. THE DECISION SUPPORT SYSTEM 



This chapter presents our design for the fleet mix planning decision 
support system. We begin developing and structuring the DSS by exploring 
four main issues relevant to it: the application theory, the conceptual 
approach, the representations and the operations of the system. Each of 
these areas will be discussed in the first section of this chapter. The second 
section of this chapter will examine and present methods for evaluating and 
comparing fleet mix alternatives. 

A. DSS DESIGN 

1. Application Theory 

The application theory answers the question "What will this system be 
used for, how can it be useful, and why is it needed?" Broadly, the purpose of 
a DSS is to assist decision makers regarding alternative courses of action. In 
the context of fleet mix planning, what is needed is a DSS that can tackle the 
problem in parts. The DSS can then be immediately useful, without having 
to solve the entire problem. The DSS can be enhanced until the problem is 
sufficiently solved or the investment of time doe. ' ot add significant value. 
This incremental, iterative process to the DSS approach will provide the 
decision maker with a system that is of immediate use. It can be expanded as 
organizational confidence grows and as its results are accepted. 

Also, the DSS provides the user valuable information about various 
facets of fleet planning in one easily accessible system. Information about 
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ships, costs, crew sizes and homeport facilities will be available through the 
DSS. 

a. System Use 

The intended application of the system can be classified into three 
broad categories. First the system will provide features to evaluate various 
characteristics of a fleet mix alternative that bear on the decision. Second, the 
system will provide features to create and analyze data scenarios to evaluate 
important attributes of the fleet mix alternative. A solution obtained from 
analysis of many possibilities should account for much of the uncertainty in 
the environment, (discussed in Chapter II) and should be robust and less 
sensitive to changes. Third, we will emphasize system features that allow 
users to justify decisions that may be reached on the basis of these results. 

b. Need for Decision Support 

The primary goal of this research is to provide a tool that meets 
existing needs in the Coast Guard. A listing of the Coast Guard's needs for 
support in the acquisition process is provided in [Ref 3:p. 8]. Some of those 
needs are consistent with the objectives of this research and are quoted 
below: 

• An existing need to replace an aging fleet of capital assets. 

• A policy and political environment in which funds are in short supply. 

• Vessel acquisitions are complex and difficult, and require years of effort 
and planning. (Typically 5-10 years elapse between initiation of an 
acquisition project and actual construction of new assets. Ships remain 
among the most complex of human artifacts.) 

• Complexity and difficulty are increased by new technology, changing 
mission requirements, and the fact that fleet mix planning becomes 
more critical with limited resources. 
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• Analysis of alternatives has been weak and previously done without 
extensive management science techniques. 

• Shortage of personnel; existing personnel are overextended and must 
answer many difficult questions from the Department of Transportation, 
Congress, etc. The Coast Guard requires a fast, accurate, and consistent 
way of responding. 

• The costs of mistakes and vagueness are high, with the costs measured 
in credibility with the Department of Transportation and Congress, and 
in dollars paid to contractors for Coast Guard mistakes and to attorneys 
for litigation support. [Ref 3:p. 8-11] 

The DSS provides decision makers with a tool that will facilitate the 
evaluation of fleet mix alternatives. It will have the ability to perform ad hoc 
queries on data about fleet mixes. In addition, the DSS breaks the complex 
fleet mix problem into manageable and understandable parts for the user. 

2. Conceptual Approach 

We have discussed the application theory of the DSS in the above 
paragraphs. To help clarify and illustrate how the system should be delivered 
and what the system should look like, we discuss the conceptual approach 

underlying our system. Our conceptual approach will be to: 

• develop a set of measurable key characteristics of a fleet mix. 

• group the characteristic measures into the three primary measures: cost 
measures of a fleet mix alternative, activity measures of a fleet mix 
alternative, and performance measures of a fleet mix. 

• present the characteristic measures in a hierarchical environment that 
uses a hypertext presentation system [Ref 9:p. 3-8]. 

The three types of measures entail: a) cost measures that will be 
provided by the Coast Guard, b) activity measures that will also be primarily 
provided by the Coast Guard, and c) performance measures that produced 
using the simulation model developed in our DSS. 
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3. Representations 

The DSS is able to represent a diverse set of information such as 
cutters, homeports and events. In particular, the following items will need to 

be represented in the system. 

• Characteristics of a ship. 

• Homeport pier facilities and location. 

• Coast Guard Districts. 

• Components of a fleet mix. 

• Characteristics of an event. 

• Simulation inputs. 

• Rules 5 about dispatching cutters to a mission. 

• Models and formulas. 

The DSS will provide internal and external representations in order to 
capture the information required. 

a. Internal Representations 

The internal representations of the DSS will include data structures 
and rules in the knowledge base. In particular, relational data tables will be 
used to store data about the ships, homeports, pier facilities, districts, events, 
and fleet mixes. A model base will be used to store the rules and models 
required by the DSS. 

b. External Representations 

The external representations of the DSS will include data entry 
forms, tabular reports, icons and buttons in a hypertext environment. Data 



5 Rules are used to represent the logic required to take actions such as 
assigning ships to events. Rules decide the proper action to take when an 
event is called and executed. 
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entry forms will be used to allow the user to input the data required about a 
new ship, a fleet mix, and a simulation run. Tabular reports will be used to 
display simulation results, fleet mixes, homeports in a district, and 
simulation inputs. Icons will be used to represent types of ships and events. 
Buttons will be used to represent navigational commands, start-up 
commands and execution commands. 

4. Operations 

Operations on the information structures are supported by the 
following user capabilities. 

• Perform simulations on selected fleet mixes and scenarios. 

• Aggregate simulation results. 

• Present the results in a final results format. 

• Create a new ship, an alternative fleet mix, or a scenario. 

• Modify ship characteristics, homeports, districts, fleet mixes, 
performance tempo, and sea state conditions. 

• Print reports as required: Simulation results. Cost and Performance 
Measures, and data retrieved from a database. 

In summary, we have defined the four main issues relevant to the 
development and structure of the DSS. This section also discussed what the 
user will use and see in the DSS. In the following section, the emphasis shifts 
to the functionality of the DSS and how the system will achieve the items 
discussed above. 

B. FLEET MIX EVALUATION 

The DSS provides results for alternative fleet mixes in three significant 
attributes. The first attribute is the cost of the fleet mix. The second is the 
potential activity of the fleet mix. The third is the performance of the fleet 
mix. 
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1. Lifecycle Cost 

The OMB Circular A-109 requires an analysis of the lifecycle cost of a 
proposed patrol boat capability replacement [Ref. 10:p. 4-14]. The lifecycle cost 
for the fleet of patrol boats is more difficult to define, since some patrol boats 
are nearing the end of their service life, some are new, and some have not 
been built yet. The lifecycle cost for one vessel is the sum of the costs in the 
following categories: 

• Ownership costs include acquisition cost, mid-life refurbishment costs, 
and salvage / disposal costs. 

• Operating costs include fuel, oil, lubricants and hotel costs (food, 
blankets). 

• Maintenance costs include preventive and corrective maintenance costs. 

• Personnel costs include the standard billet costs for the assigned crew 
and designated support personnel. [Ref. 11] 

These costs are distributed throughout the service life of the vessel. To 
provide a means of comparing alternatives, the present value of the cost is 
computed using discount factors and is called the lifecycle cost. The 
annualized lifecycle cost is the uniform annual payment over the service life 
of the vessel equivalent to the lifecycle cost. The DSS computes the total of 
the annualized lifecycle costs for the fleet mix alternative. 

The individual components for the cost attribute within the current 
version of the DSS will be entered by the Coast Guard users. A spreadsheet 
application is planned for computation of the lifecycle cost. The values for 
cost in each category and the timing of the cost will be entered by the user. 

2. Activity 

The attribute of potential activity relates to the time available during a 
year for each of the patrol boat's required tasks. These activities include 
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maintenance, standby, patrol and crew rest. The user can enter and modify 
numbers in each category for a specific class patrol boat. The DSS computes 
the activity for the entire fleet mix alternative. 

3. Performance 

Our approach evaluates performance using a computer simulation. 
The method measures performance of a fleet mix of cutters in a situation that 
simulates the operating environment for the patrol boats. The basic idea of 
the simulation approach is simple. Each alternative fleet mix is evaluated 
under a scenario representing a fragment of real-life demand on the Coast 
Guard's fleet. This evaluation is performed by simulating responses to 
random events, and measuring the costs and performance of the results of 
these responses. By repeating this evaluation over a variety of scenarios that 
could represent future demand (given the information known today), these 
results will represent a robust and fair evaluation of the fleet mix. By 
evaluating each fleet mix under the same set of scenarios, we can get a 
comparative evaluation of the alternative fleet mixes. 

Several models are needed within the simulation process. These are 
an event manager for random event generation, a dispatch model for 
selecting the cutter to send on a mission, an inter . pt model to compute the 
dispatched patrol boat's course in order to intercept a suspected vessel, a ship 
movement model to update each ship's position at each interval and an 
operations manager to control changes to a vessel's assignment. 

a. Event Manager Model 

The event manager determines if an event occurs during a time 
interval. First, the model generates a random number. If the number falls 
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within a certain range, no event occurs. If the number is in another range an 
event occurs. A second random number is used to select the type of event, its 
location and other event details. The details for the events are drawn from a 
table of typical patrol boat events such as SAR cases and drug boat traffic. 

b. Dispatch Model 

The dispatch model uses information about the most recent event 
to assign the appropriate cutter to the case. The location of the event (such as 
a ship in distress) and the type of event are the key variables. This model was 
developed through interviews with various Coast Guard officers. The event 
manager first makes a list of patrol boats available for assignment to the 
mission. The SAR mission has the highest priority, and a vessel could be 
diverted from another lower priority mission if necessary. Patrol boats in the 
standby condition (inport) will be directed to respond if required. Patrol boats 
are not considered if they have insufficient fuel or are due to complete a 
patrol within a day. In the case of a moving target, the vessel that is in the 
best position to intercept the moving vessel (normally a drug boat) is 
assigned. In the case of SAR, the vessel that can get to the scene first is 
assigned to a SAR case. Other types of missions are assigned to the closest 
vessel with the capability. 

c. Intercept Model 

The intercept model uses information about the location, course 
and speed of the vessel to be intercepted, the location, and maximum speed 
information of the patrol boats eligible for assignment. Typical geometry of 
the situation is shown in Figure 3-1. The position of ships is indicated by x 
and y coordinates on a grid representing the Coast Guard district. The goal is 
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to select the cutter that is in the best position to intercept the drug boat, and 
compute an intercept course for the selected cutter. The problem is solved 
using the following steps. 

• Assumptions: The computations assume the position of both vessels 
are known, the target vessel course and speed are known, and that the 
target doesn't change either course or speed. In reality if target course or 
speed changed, the patrol boat would compute a new intercept course. 

• The basic approach to finding the intercept course relies on a line-of- 
sight diagram (Figure 3- 2). The distance to the target vessel and the 
bearing to the target vessel is determined. The target course is plotted on 
the upper end of the diagram, and the speed is indicated. The target has 
speed across the line-of-sight and speed in the line of sight. By selecting a 
course for the patrol boat that has the same speed across the line-of-sight, 
the patrol boat will achieve the fastest intercept of the target vessel. Note 
that some of the patrol boat speed will be in the line-of-sight, tending to 
reduce the range to the target. The process is illustrated below. 
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Figure 3-1 Geometry of Target Intercept. 
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Figure 3-2 The Line-of-Sight Diagram for Determining Intercept Course. 
• Compute the range between the vessels. 

Range = -X ,) 2 + (Y p - Y ,) 2 



• Compute the bearing to the target vessel. 
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• Compute the angle (a) between the target course and the line-of-sight. 
This angle will be used to compute the target speed across (perpendicular 
to) the line-of-sight and speed in the direction of the line-of-sight. 



a = 180 - (Target_course - Bearing_to _target) 



• Compute the target speed across the line-of-sight. 



Speed _across_LOS = Target_Speed x Sin a 



• Compute the angle (|5) between the line-of-sight and the patrol boat 
course. This course is selected to have the same speed across the line-of- 
sight as the target vessel. The other condition for the course is that it be 
closing the target rather than opening. 



Patrol_boat_speed x sin ft = Target_speed 
/ \ 



P = 



Arcsin 



Target _speed. x Sin a 
Patrol _boat_Speed 



/ 



x sin a 



• Compute the patrol boat course. There are two cases: either a target 
course on the left side of the line-of-sight (port) as shown in Figure 3-2 or 
the target course on the right side of the LOS (STBD). 



For a Port LOS: Patroljboat jcourse = Bear ing_to_tar get - ft 
For a STBD LOS: Patrol _b oat _course =Bearing_to_target + (5 



• The time to interception is computed. Again there are two cases: If the 
target is opening (we see his stern), the speed components subtract. The 
patrol boat will be chasing the target. The second case is a closing target 
(we see his bow)as illustrated in Figure 3-2, and the speeds add as shown 
below. 
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Relative _speed_in_the LOS = Target_speed x cos a + Patrol _boat_speed x cos /? 

^ . . Range 

Time_to -intercept = —— — ; — ——— 

Relative_Speed_in_the_L O S 

The intercept model computes the time to intercept for each patrol 
boat that is eligible for assignment. The patrol boat with the minimum 
intercept time probably will have the best opportunity and geographic 
position to intercept the target and perform the mission. Other patrol boats 
could have a very long intercept time if they are chasing the target from 
behind. The boat with the minimum intercept time is assigned to the 
mission, its speed is changed to maximum and it' course is set to the intercept 
course. 

d. Ship Movement Model 

The ship movement model computes a new position each interval 
for any vessel (patrol boats and drug boats) based on its assigned course, speed, 
and the previous position. The positions are computed using the following 
relationships: 

X 2 = Xi+(x _component _ of _speed x Time) 

X 2 = Xj + Cos( 90 - Vessel _course) x (V ess el speed ) x T 

Y 2 = Y\ + Sin(90 - Vessel _course) x (Vessel speed ) x T 

• where T is the time interval (one hour) 

• (90 - Vessel_course ) is the conversion of the vessel's course measured 
in degrees relative to north to an angle relative to the X axis as shown in 
the Figure 3-3 below. 
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Figure 3-3 Geometry of Vessel Motion. 
e. Ship Operations Manager 

Some situations will require a change in the patrol boats operating 
conditions. The dispatch and intercept models make changes to course and 
speed in response to a new mission. The ship operations model makes 
changes in all other conditions. Some of these conditions are that the patrol 
boat is low on fuel and must refuel, or that the patrol boat has completed its 
patrol and returns to port, or the patrol boat reaches it 7 s destination and must 
slow to render aid. The need for change is nor ' ly detected by the ship 
movement model, as it routinely checks the quantity of fuel remaining, days 
underway and the distance remaining to the destination. When the ship 
operations model is called, a parameter is set to indicate the present condition 
and the change necessary. 
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We have discussed the design of the DSS and the methods for evaluating 
fleet mix performance using the DSS. Chapter IV presents our 
implementation of this design in an operational DSS prototype. 
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IV. IMPLEMENTATION OF FELIX 



The system design described in Chapter III has been implemented in a 
prototype DSS called Felix. This chapter presents the implementation process 
of the DSS and highlights the major components of the system. In addition, 
transfer of data and control between three different software products is 
discussed. A brief description of the hardware and software selected for the 
implementation of the DSS is first introduced. 

Initial requirements for Felix were that the user interface be built with a 
hypermedia software application, and that a relational type database be used. 
Felix is implemented and runs on the Macintosh® II family of machines 
with eight megabytes of random access memory. The database was developed 
using a relational DBMS labeled ORACLE® (version 1.2 published by Oracle 
Corporation), the interface was developed using SuperCard® (version 1.5 
developed by Silicon Beach Software), and the model base was developed 
with Nexpert Object® (version 2.0 published by Neuron Data). 

A. APPLICATION INTERFACES 

Ensuring that all three products could communicate with each other was 
the most important factor in the selection process. Oracle is a relational 
database that is specifically designed to take advantage of a hypermedia 
software application. SuperCard is a newly developed hypermedia software 
that advances the original HyperCard® environment made famous by 
Apple®. Nexpert is an expert system shell that provides interfaces for 
several of the well known software products. We will briefly discuss how 
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each software package communicates with the other two and how they 
provide the interface process that is required for the implementation of Felix. 

1. Oracle 

Oracle databases are managed by the Oracle Relational Database 
Management System (RDBMS). The data within the tables is accessed by using 
commands issued in Structured Query Language 6 (SQL). Oracle provides 
additional features to interface with other software applications. The two 
features required to interface with SuperCard and Nexpert are addressed 
below. 

a. Hyper*SQL 

Hyper*SQL is an Oracle application which allows the database tables 
to be accessed from a hypermedia software application, such as SuperCard. 
The access commands (initiated from SuperCard) allow the user to initiate 
Oracle database operations, such as starting and stopping Oracle, logging on to 
a database, creating database objects, performing queries, inserting and 
updating data, and monitoring error and control messages through 
Hyper*SQL scripts 7 [Ref. 12:p. 4-1]. 

b. Pro*C 

Pro*C provides an environment in which the user can use a C 
language application (such as Nexpert) to access the database tables. The C 



6 SQL is an English-like, non-procedural language defined by IBM™ 
Research and introduced to the commercial market in 1979. 

7 A script is basically an informal small computer program written in the 
appropriate language that executes whenever the user takes some action. For 
example, the user may click a mouse button or select a command from a 
menu to commence an action. 
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language program is translated by the Pro*C precompiler into equivalent SQL 

commands. Some of the features of the Pro*C precompiler are: 

• Each SQL statement is automatically translated to the equivalent 
runtime library calls, reducing programming time. 

• A single Pro*C program can be created to operate with data from 
different Oracle databases. 

• Multiple Pro*C programs can be separately precompiled and executed 
together in the same application [Ref. 12:p. 9-1]. 

2. SuperCard 

SuperCard uses a scripting language called SuperTalk to perform 
internal operations. An external command facility (XCMD) allows developers 
to write SuperCard applications that communicate with external programs 
including Oracle and Nexpert [Ref. 9:p. 145-147]. 

a. XCMD for Oracle 

When SuperCard encounters the external command EXECSQL in a 
script, the remaining program line is passed from SuperCard to Oracle 
through the Hyper*SQL interface. An example of an EXECSQL command 
embedded in a script would be: "EXECSQL Select SEQUENCE from 
SIMULATION_QUEUE." 

b. XCMD for Nexpert 

SuperCard has two way communications with Nexpert by using the 
external command NXP. In addition, the Nexpert Dynamic Library (NDL) and 
the Nexpert Handler Interface (NHI) files must be installed in the System 
folder. NDL provides access to the system features of Nexpert from other 
programs and the file NHI is the file that passes message between SuperCard 
and Nexpert. 
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3. Nexpert 

Nexpert provides the developer several flexible methods for 
communication with external programs and databases. The Nexpert Database 
bridge and HyperBridge provide an easy interface to Nexpert compatible 
applications. The database bridge supports a wide variety of file and database 
formats but we will discuss only the process for linking Nexpert with Oracle 
[Ref. 13]. The Nexpert HyperBridge consists of several modules which enable 
the Nexpert Dynamic Library to be accessed directly from SuperCard scripts 
using XCMD commands [Ref. 14:p. 1-20]. 

a. Database Bridge 

The Nexpert Database bridge is invoked when Nexpert processes a 
Retrieve or Write command. The Retrieve command moves data from 
Oracle into Nexpert’s working memory, the Write command moves data 
from Nexpert's working memory to Oracle. The bridge does much more than 
simply transfer data; it also transforms it between Nexpert's class-object- 
property representation and Oracle's format [Ref. 13:p. 57]. The specific 
implementation process can be found in the Nexpert Object Version 2.0 
Database Integration Guide. Briefly, the implementation process uses the 
Nexpert Database Editor to list the available database interfaces already built 
into Nexpert. The keyword ORACLE is used by Nexpert to designate an Oracle 
database. The keyword is used before each call to the appropriate database. 

b. Nexpert HyperBridge 

The Nexpert HyperBridge integrates Nexpert to other applications 
through its runtime library. The Nexpert Handler Interface (NHI) is the 
interface from Nexpert to the SuperCard script. This handler is used to return 
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messages to SuperCard. The NDL receives the NHI message and translates 
the message into the proper code for use by SuperCard. 

The interfaces between programs are an important part of 
developing any program and was a critical one in the success of Felix. We 
have introduced the intricate process of connecting the three programs 
selected in building our DSS. Specific details of each were omitted but the 
important interface commands were briefly discussed. In the following 
section, we present the modules within Felix. 

B. FELIX MODULES 

Felix is implemented in three components that are directly related with 
the three selected software products. The first component is the Oracle 
database. The second component is the user interface that was developed 
with SuperCard. The third component is the model (including math and 
deductive models) base, developed in Nexpert. Figure 4-1 illustrates the 
design of Felix. In this system, the user will work directly with the user 
interface. The user interface will access the DBMS and knowledge base as 
required by the user. The DBMS will access the appropriate data files in 
storage. The knowledge base will access the mc-^^ls, objects and rules as 
needed to complete the task requested by the user, in addition, the knowledge 
base may require a data file and will access the DBMS. Each of these three 
components has several interface modules that complete separate tasks 
within the component. We explain each component's internal modules and 
its external relationship with the other two major components in the 
following paragraphs. 
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Figure 4-1 Configuration Layout of FELIX. 

1. Orade Database 

The database management system (DBMS) consists of a database with 
data tables that store the DSS data. The database is the passive component in 
the system. It only provides a data repository service to the other components. 
Figure 4-2 illustrates the external relationships with the user interface and the 
model base, and the internal modules. 
a. External Relationships 

The tables stored in the database are used by the user interface and 
the model base. For example, the model base requests values from a table 
stored in Oracle and uses that data as inputs to a model or rule. Afterwards, 
the output data of the process is transferred to the database for storage. The 
relationship with the user interface is similar. The user requests information 
from the database. The data is transferred and returned to storage upon 
completion. 
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Figure 4-2 DBMS Layout Design. 



b. Internal Modules 

The data within the database is classified into two general groups. 
Fleet Mix data and Evaluation data, each of them having several tables. In the 
Fleet Mix data group, the tables include data that pertain to the Coast Guard 

cutters. Examples of these data tables are: 

• Cutter Characteristics Table: Captures important data about a specified 
cutter, including Max Speed, Length, Beam, and several others. 

• Fleet Mix Tables: Captures the type and quantity of cutters that comprise 
the specified fleet mix, including WPB-80's, WPB-82's, WPB-110's and 
WPB-120's. 

• Homeports Table: Captures the data required to identify the location and 
facilities of a homeport, including the City, State, District, Restrictions, 
and Limitations. 
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In the Evaluation data grouping, the tables store required data 
needed to run the evaluation process and the results from an evaluation. 

Examples of this type of data are: 

• Simulation Queue Table: Captures information about the next 
simulation to run, including Fleet Mix selected. District, Sea State, Sea 
State Trend and Operation Tempo. 

• Events Table: Captures information about six different possible events 
that could occur in a simulation run. 

• Simulation Results Table: Captures information about the results of the 
simulation, including SAR Missions, ELT missions. Failed SAR 
Missions and several others. 

2. User Interface 

The Felix user interface is an interactive system designed to allow the 
user to quickly master Felix. The primary design goals are to provide the user 
a friendly easy system and to provide a system that can be easily enhanced as 
the need arises [Ref.l5:p. 9]. In our first goal, we refer to the user interactions 
with the tasks and sub-tasks that must be carried out within Felix. Task 
functionality is centralized so that the user can quickly return to a familiar 
section of Felix (mainly the main menu). Excessive functionality is kept to a 
minimum so as not to confuse or frustrate the user. The screens presented to 
the user are similar and consistent in format and enhance the user’s comfort 
with Felix as he quickly masters the program. The second goal of ensuring 
adaptability of the system refers to the quest for a modular design and correct 
performance. 

The user interface design is displayed in Figure 4-3. The external 
relationships will be discussed in the next paragraph, followed by the internal 
modules of the user interface. 
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a. External Relationships 

The external relationship of the interface with the DBMS is similar 
to the data transfer process discussed in the previous section. The user 
interface calls a table from the DBMS for the user to view, print or modify. In 
addition, the user interface transfers new data to the DBMS as created by the 
user. The data could be from any of the tables within the database. 

The external relationship with the model base is a program control 
transfer. The call to the model base will relinquish control of the system to 
the Nexpert program. The model base returns control to the user interface 
upon completion of the called evaluation process. 

b. Internal Modules 

Within the user interface there are four modules: the Online Help 
system, the Data Retrieval/Insertion/Update module, the Report Generator, 
and the Model Base Control. The four modules are briefly discussed below. 

The Online Help System is found on each of the display screens 
within the user interface. The user can obtain additional help information by 
pressing the Help button provided at the bottom left corner of each screen. A 
scrolling window will appear containing information that explains each 
option available on the displayed card. An additional feature of the Online 
Help system is the presence of additional bottom row buttons that provide the 
user with an easy method of returning to the main menu. 

The Data Retrieval/Insertion/Update module allows the user to 
retrieve the tables within the database and modify them as necessary. 
Additions, deletions and changes are common requirements in any system. 
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and are easily performed in Felix. Additional features of this module are the 
Start/Stop buttons for Oracle and the Oracle Log On process. 




Figure 4-3 The User Interface Layout. 



The Report Generator provides the user with the ability to print 

different reports. Examples of the items available for printing are: 

• Aggregate Fleet Results: The report that lists the final measures to be 
used by the decision maker. 

• Homeports: A list of all the homeports used by the Coast Guard and the 
facility limitations. 

• Fleet Mix: A list of the select fleet with information about the vessels 
and homeport placement. 

• Simulation Result: List the measures of a single simulation run. 

The Model Base Control provides the user the ability to initialize 
Nexpert and select the evaluation process. The evaluation process is started 
when the user selects a button on the Model Base Control card. The user 
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initiates fleet performance evaluation by selecting the Perform Simulation 
button. Similarly, the user initiates aggregate results of performance 
simulations by selecting the Aggregate Results button. Buttons are provided 
for Evaluate Costs and Evaluate Activity, but this feature was not provided in 
the initial prototype version. 

3. Felix Model Base 

The model base for the DSS provides two types of environments for 
knowledge based applications: the development environment and the 
Nexpert Dynamic Library. The development environment is the more 
powerful of the two and is used to build and modify new applications. These 
applications are stored as individual program files to be accessed as required. 
The development environment also provides templates for defining rules, 
classes, and objects. In addition, it provides the knowledge processing 
function that can be controlled step-by-step if necessary for testing. In 
comparison, the Nexpert Dynamic Library provides access to the knowledge 
processing features of Nexpert, but does not provide the editing features. 

Nexpert uses rules to represent intelligence, and objects to represent 
entities in the real world. The logic of the model is written using rules that 
reference objects such as patrol boats and object prc r ,rties such as speed of the 
patrol boat. The logic for the models in the model base was presented in 
Chapter HI. 

The model base in Felix, illustrated in Figure 4-4, is a Nexpert 
application with a knowledge base file for each evaluation process. The user 
interface calls the Nexpert Dynamic Library to perform evaluation of the fleet 
mix using the proper knowledge base file. The external relationships section 
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describes the purpose of the model base and its place within the DSS. The 
internal modules section describes the operation of the models within the 
model base. 

a. External Relationships 

The model base is called by the user interface to perform various 
types of fleet mix evaluation and analysis. These calls are basically program 
control calls. Control of Felix is relinquished by the user interface and is given 
to Nexpert as the selected evaluation is being processed. Upon completion, 
control is returned to the user interface. 

The relationship of the model base with the database is a basic data 
transfer. The models retrieve data from the database and write data to the 
database as required for analysis. This process is controlled by rules within 
Nexpert. 

b. Internal Modules 

The internal logic of the evaluation modules was presented in 
Chapter HI. Specific aspects of the model base implementation are discussed 
below. The simulation and aggregation models are written using Nexpert 
and are stored as a Nexpert knowledge base. The activity and cost modules, 
although not implemented, are included for discussion. 

The simulation model is called by the user interface and performs 

the following steps: 

• Read in simulation data 

• Read in fleet mix data 

• Read in Event data 

• Perform the first simulation run 

• Write results to the simulation results table. 
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• Repeat the above process until all runs in the simulation queue have 
been performed. Nexpert returns execution control back to the user 
interface. 

The result aggregation module is also called from the Model base 
control card in the user interface. The aggregation performs the following 
steps: 

• Read in the data for the fleet mix being aggregated. 

• The simulation results are first combined by district. 

• The district results are then combined for a fleet. 

• Upon completion, the results are stored in the database and program 
control is passed to the user interface. 




Figure 4-4 The Model Base. 



The activity module will evaluate the measures that would 
determine if the fleet could meet the projected modes of operation. The 
evaluation process will include assessing maintenance hours, patrol hours. 
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crew relief hours, and stand-down hours. The focus will be to analyze the 
extent to which a selected fleet mix can provide the required hours for each 
phase of a cutter's lifecycle. 

The costs module will evaluate the costs associated with a fleet mix. 
Some of these costs include lifecycle, acquisition, operations and maintenance 
(O&M), and manning. 

This chapter has presented a description of the DSS prototype 
developed as a part of this research. The application interfaces, user interface, 
database and the model base were described. The next chapter will present a 
user's point of view and will examine the results of a sample simulation. 
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V. FLEET MIX ANALYSIS USING FELIX 



The procedures for using Felix to evaluate alternative fleet mixes are 
presented in this chapter. In addition, we present considerations that should 
help the user analyze the results of a simulation run. 

A. WORKING WITH FELIX 

In this section, we illustrate the steps required to set up and run a 
performance evaluation of fleet mix alternatives. Specifically, we address how 

the user will: 

• define a new fleet mix. 

• select parameters as initial conditions for the simulation process. 

• perform the simulation. 

• analyze the results. 

1. Initial View 

Initially, the user will view the main menu of Felix. This is illustrated 
in Figure 5-1. Several operations are possible from this screen. We will only 
discuss the process of stepping a user through a typical simulation process. 
Other options available to the user are explained in the Felix user's manual. 

The first action required by the user will be to start the Oracle database 
by selecting the Start Oracle button. Internally, the procedures described in 
the previous section will occur and the link between the user interface and 
the database will be established. The user may define a new fleet mix 
alternative, modify a fleet mix alternative or continue with the simulation 
setup of all fleet mix alternatives already defined. To build a new fleet mix 



46 



alternative, the user selects the Build Fleet button. Felix will display the 
screen illustrated in Figure 5-2. 



U.S. Department 
of Transportation 
United States 
Coast Guard 




Felix 

Decision Support 
System 




Menu 



S8S8 




Figure 5-1 Main Menu in Felix. 

2. Build a Fleet 

Two screens are used to build a new fleet. In the first screen, the user 
assigns a fleet mix number and selects the number of patrol boats for each 
class. When completed, the user selects the Done button; the second screen in 
the Build Fleet process appears. The user assigns each vessel to one of the 
listed patrol boat homeports. The homeports are automatically linked to the 
proper Coast Guard district within the DSS. The result is a fleet mix 
alternative that defines the vessel class, homeport and district for each boat. 
Up to five fleet mix alternatives can be defined and stored in the DSS in this 
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manner. Upon completion, the user selects the done button and is returned 
to the main menu. 
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United States 
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Felix 
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File to be Built: 
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WPB82 

WPB110 

WPB120 

WMEC 

WHEC 

WSES 

OTHER 



i 



Help 



It 



Uietu Inserts 




Figure 5-2 Build Fleet Mix Screen. 

3. Simulation Process 

To set up the simulation, user selects the r ’tn Simulation button on 
the main menu. Felix will display the Simulation input screen as illustrated 

in Figure 5-3. Each simulation run is defined as follows: 

• select one of the eight fleet mix alternatives. 

• select a district for evaluation. 

• select the initial sea state (weather condition). 

• select the trend in the sea state (how the sea state changes during the 
run). 
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• select the tempo of operation (a parameter which will eventually control 
the rate of random event occurrence). 

The parameters for the first simulation run are now defined and are 
stored in the Simulation Queue data table. The user may enter additional 
simulation runs, varying the fleet mix number, the district and initial 
conditions for the simulation. One requirement is to evaluate each fleet mix 
alternative in each district under a variety of conditions. Another 
requirement is to evaluate each fleet mix alternative under the same set of 
simulation parameters. 



U.S. Department FollX 

of Transportation FLEET MIX: l|&| 

United States Decision Support 

Coast Guard System 


%^5%Simulation Inputs Required >$$$$$$$: 


Select Fleet Mix to be Used: 

FMOl| FM02| FM03| |FM04| FM05| FM06| FMO?| FM08| 


$6 ect District to be Used: 


.Tempo: 

□ Normal 

□ Hiflh 


Select Sea State Condition: 

0 q 0 0 0 0 0 grrr, 


[Clear Simulation QueueJ 


Help ^ View Que Cancel fr^dd to Que^rf: 


Save ferj] Execute ^ 



Figure 5-3 Simulation Inputs Screen. 

With the simulation queue loaded, the user selects the Execute button 
to initiate the simulation. Felix displays the Model Base Control screen. First 
Nexpert is initialized. The process described in the interface section 
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establishes a link between the user interface and Nexpert. Next the user 
selects the Perform Simulation button. Program control passes to Nexpert. 
The first entry in the simulation queue table is read. The patrol boats for the 
selected fleet mix and district are positioned on an imaginary coastal ocean 
area. Some vessels are at sea on patrol. Other vessels are inport either in a 
standby condition or in a maintenance condition. A random event occurs at 
some location. The simulation dispatcher selects the boat that should 
respond to the event. The intercept course is computed for the selected patrol 
boat and its speed is set to maximum speed. The model computes values for 
measures such as the time required to intercept a vessel, and the fuel used. 

The process is continued for a simulated time of one week, with 
random events occurring throughout the 168 hour time frame. Results for 
the simulation run are stored in a data table for later processing or review. 
The next run in the simulation queue is read in and the process repeats. The 
simulation continues until all Simulation Queue table inputs have been 
evaluated. 

The user may aggregate the simulation results or return to the main 
menu. By selecting the Aggregate Results button, the Felix aggregation model 
first combines simulation results by district within a specific fleet mix 
alternative. For example, five simulation runs were performed on FM02 in 
District 7. The first level of aggregation combines the results for District 7 of 
FM02. The first level aggregation is continued until results are combined for 
each district of each fleet mix alternative. The second level of aggregation 
combines the district results for each fleet mix alternative. The result is a 
display of measures for each fleet mix alternative in the final results screen. 
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The summary information of one fleet mix is presented with similar 
information for the other fleet mix alternatives. Assessment of the final 
results is discussed later. 

4. Typical Results 

At the Main Menu, the user selects the Final Results button and a 
layout similar to TABLE 5-1 is displayed on the screen. The numbers are 
provided for demonstration purposes, and have no relationship to a real 
fleet. Additionally, the cost and activity measures are not computed in the 
current implementation. The user has the option of printing the results table 
or returning to the main menu. 

The user can get more information about a number on the simulation 
results by selecting that number. Another view of the data used to develop 
the number is presented. For example, the user might want to look at the 
individual simulation results that were performed during evaluation. The 
user clicks on the fleet mix number with the mouse button. A scrolling list 
appears on the screen with all the simulation runs listed. Clicking on one of 
the simulation listings causes the individual results to be displayed. Figure 5- 
4 shows sample results for a simulation run. This completes the introductory 
steps in working with Felix. Detailed information can be found in the Felix 
User's Manual and with the Online Help system within Felix. 
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TABLE 5-1 SAMPLE FLEET ANALYSIS RESULTS. 



Evaluation Measure 


FM04 


FM05 


FM05 




Costs ($ millions) 










Amortized Lifecycle Cost 


$600 


$530 


$450 
























Activity (hours) 










Patrol 


172,800 


142,800 


136,800 




Maintenance 










Defense Operations 




















Performance 










SAR response time 


3.6 hours 


4.7 hours 


4.9 hours 




Number of SAR missions 


27 


26 


27 




Number of failed SAR 
missions 


2 


4 


5 














Number of ELT missions 


1 7 


1 7 


1 7 




Number of failed missions 


4 


6 


7 




Number of ELT intercepts 


8 


6 


6 
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Felix Single Simulation Results Table 



Fleet Mix: FMOI Sea State: 5 / Increasing 

District: 8 Tempo: Normal 



Costs ($ millions) 



Fleet Mix Status 



Amortized Lifecycle Cost 



Activities (hours) 
Patrol 

Maintenance 
Defense Operations 

Performance 

SAR response time 
Number of SAR missions 
Number of failed SAR 
missions 

Number of ELT missions 
Number of failed missions 
Number of ELT intercepts 



$155 



985 

412 

116 



3.4 hrs (AVG) 
17 
2 

24 

3 

19 



WPB80 


24 


O 


WPB110 


32 




WPB120 


16 


O 



District Status 



WPB80 


6 


O 


WPB110 


10 




WPB120 


3 








o 



Homeport Status 



Mobile, AL WPB110 


O 


Galveston, TX WPB80 




Galveston, TX WPB80 




Sabine, TX WPB120 


II 


Freeport, TX WPB1 10 




Gulfnnrt MS WPR110 


o 



Help □a Print 



Done 



i 



Figure 5-4 Results for a Single Simulation. 

B. FLEET MIX ANALYSIS USING FELIX 

The process of evaluating fleet mixes has been discussed above. The most 
important use of the fleet mix DSS is to compare alternative fleet mixes. This 
section provides a discussion of the comparison process. Decision makers 
will develop and use their own policies for combining the results. The next 
section presents some considerations for use of results. The following 
questions are addressed: What do the results imply about the relative quality 
of the fleet mix? How can the decision maker use the results of the DSS to 
support his selection of a fleet mix alternative? 
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1. Performance Analysis 

The performance results are used to indicate the relative quality of the 
fleet mix with respect to meeting mission goals. The same basis for 
evaluation must be used to ensure objective comparison. Each fleet mix 
should have been put through the same test or series of simulation runs. 
TABLE 5-1 provided sample results of fleet mix analysis. The sample results 
indicate that fleet mix FM04 has a better performance in most categories 
compared to the other fleet mixes. More detail about the performance results 
is obtained by clicking with the mouse on the fleet mix name at the top of the 
column. 

2. Cost Analysis 

TABLE 5-1 indicates that fleet mix FM06 has the lowest cost figures 
compared to the other fleet mixes. The cost figures would be entered by the 
user for each class of ship, and this table would show the cost for the specified 
mix in the fleet. More detail about the costs is obtained by clicking on the 
number in question. 

3. Activity Analysis 

TABLE 5-1 indicates that fleet mix FM04 has the best activity capability 

r 

for patrol boat performance and the lowest main^nance requirement. The 
activity characteristics for each patrol boat are entered by the user. Felix 
computes the combined activity hours for the fleet mix. 

This chapter discussed use of the DSS to help the user evaluate and 
compare alternative fleet mixes. Chapter VI discusses considerations for use 
of the DSS, and presents recommendations for enhancement and 
improvement. 
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VI. CONCLUSIONS 



Felix was designed as a prototype DSS for Coast Guard fleet mix planning. 
The system has been delivered to the Patrol Boat Capability Replacement 
Project at Coast Guard headquarters. We hope that further enhancements 
and modifications will be added to improve the utility of the DSS. In this 
chapter we present the known limitations of the system, a list of possible 
enhancements to the system, and issues for further research. 

A. LIMITATIONS OF THE CURRENT IMPLEMENTATION 

There are certain limitations on the use of the current implementation of 
Felix. The DSS is applicable in a narrow range of fleet mix planning. The 
analysis methods used do not consider all the facets of patrol boat 
performance. Assumptions were made for the evaluation of fleet mix 
performance that provide a situation different from the real world. 

1. Applicability 

Felix addresses only a portion of the patrol boat acquisition planning 
phase that is one phase of the larger fleet mix planning problem. The DSS 
helps during some early phases of the A-109 process, but there are five phases 
and milestones required for a major system acquisition. Many other aspects 
of the patrol boat fleet mix problem not addressed including the size of the 
fleet, the location of the vessels and the use of other vessels to perform SAR 
and ELT missions. Considerations for improving the DSS are discussed later 
in the chapter. 
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2. Analysis Methods 

The evaluation process for performance is limited in the following 



ways: 

• The simulation is performed using tables for events and tables for initial 
assignment of vessels. The event tables can be modified to reflect any 
environment desired. Initial condition tables can be modified to meet 
the realistic positioning of ships. It is important that the data entered in 
the event and initial condition tables be representative of the fleet mix 
problem being studied. 

• The simulation occurs in a rectangular area with dimensions closely 
approximating each district. The modeling of the actual geography of the 
coastal United States was not feasible for this prototype. Similarly, 
islands and shoal water are not considered. 

• The simulation does not consider the effects of fatigue on the crew. For 
example, there is no limit on the number of ELT boardings that a patrol 
boat could perform during a day, other than the assignment to one 
mission precludes an overlapping assignment to another mission. 

• Use of other Coast Guard assets is not considered. The missions of other 
assets overlap. In reality, 40 foot boats and helicopters, along with other 
vessels perform SAR missions. Many other sensors, ships and aircraft 
coordinate their efforts at the illicit drug problem. 

3. Underlying Assumptions 

The following assumptions were made during the development: 

• Helicopters and other Coast Guard assets will not be used to respond to 
any of the events generated in Felix. 

• Navigational hazards will not be a factor in our analysis. 

• Transit time through restricted waterways do not impose speed 
limitations on the cutters. 

• The search part of SAR is not considered. The evaluation model directs 
the patrol boat to the location of the casualty. 

B. ENHANCEMENTS TO THE PROTOTYPE 

Felix is in the infant stage of development. There are several paths that 
can be taken to enhance the system via small changes to Felix. Larger 
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modifications and additions to the system are covered in Section C. We will 
discuss how the system can be enhanced in four major categories: Program, 
Data, Maintenance and Security. 

1. Program Enhancements 

Program enhancements include coding, scripting, icons, color, sound 
and new software applications. The following are some of the program 

enhancements we would like to see added to Felix. 

• Provide a selection of randomly generated event scenarios for the 
simulation. Each event scenario specifies a sequence of events that will 
occur during the evaluation. Different scenarios would test different 
aspects of patrol boat performance. 

• Provide a selection for the patrol boat initial conditions for the 
simulation. The initial conditions include the location, fuel remaining, 
hours underway and the current mission of the patrol boats within the 
district. Evaluation with different initial conditions will reduce the 
evaluation bias that might otherwise be caused with only one initial 
condition for the start of the simulation process. 

• Allow the user to define a simulation set. A simulation set specifies all 
the simulation runs to be performed on a fleet mix. The simulation 
parameters for each run are also specified. By evaluating each fleet mix 
using the same simulation set or sets, the user is assured of a common 
base for comparing performance of fleet mix alternatives. 

• Provide color enhancements to the user interface if justified. The 
capability exists with the present design, but it was not implemented. 

• Provide sound enhancements to the user interface. This feature could 
help the user identify the type of error committed and provide extra 
clues about the location within the program. 

2. Data Enhancements 

Data enhancements provide additional information that could be used 
by Felix to facilitate better analysis for the decision maker. Several of the tasks 
accomplished in Felix use data that is entered by the user. The best method 
would be to gather and analyze appropriate historical data. The DSS could 
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use actual historical data to develop event tables or produce probability 
distributions that could be used in a Monte Carlo type of simulation. 

Examples where this method may be useful are: 

• the distribution of SAR cases in the water around the major harbors, 
waterways and channels. 

• the analysis of historical costs to be used in lifecycle cost computation, 
(maintenance, overhaul, mid-life maintenance, operations, etc.) 

• the location of fish havens that are most likely used by fishing fleets. 

3. Maintenance Enhancements 

Presently, the maintenance module of the DSS has not been 
implemented. The design of the interface delivered with Oracle and Nexpert 
do not provide for maintenance through the SuperCard interface. 
Maintenance of the user interface is performed using SuperEdit, a program 
delivered with SuperCard. It comes with all the tools for designing new 
SuperCard applications and modifying existing applications. Additions and 
modifications to the database structure and design are performed using the 
Oracle System Stack. This is a HyperCard stack that provides the database 
administrator the features to manage access, tables and data. Any access to the 
Oracle database requires a valid user name and password. The model base is 
modified using Nexpert' s development environment. New models can be 
developed entirely within Nexpert or can be called using some of Nexpert's 
built in features for accessing external programs. 

Enhancements to the Maintenance module would include a call from 
the user interface to Nexpert that would completely shut down the user 
interface after connection. Nexpert could then be used in the development 
mode to do maintenance requirements. Upon completion, Nexpert would 
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restart Felix, establish a link and pass program control. A similar process 
would be required for Oracle. 

4. Security Enhancements 

The DSS security involves two phases. The first is controlling access to 
the computer through physical security. The second phase involves 
computer hardware or software that restricts computer use to authorized 

persons. The security measures implemented by software in Felix are: 

• Access to the Felix DSS user interface is password controlled. Other 
SuperCard applications are not protected. 

• Access to Oracle requires user name and password. 

• Access to Nexpert Object is not restricted but, access to Nexpert is 
controlled by use of a hardware key that must by installed for proper use. 

C. ISSUES FOR FURTHER RESEARCH 

The DSS discussed in this thesis was designed to allow the developer or 
user to make improvements and modifications within the existing 
framework. Several enhancements have already been discussed. Other 
major areas for research include development of other models and expanding 
the scope of problems addressed by the system. 

1. Cost Models 

Cost analysis is not provided in the initial version of the prototype fleet 
mix DSS. Determination of cost is an important aspect of the fleet mix 
problem. This is an important component for further development. The 
costs models could be developed within Nexpert or could use Nexpert's 
features to call an external program like an optimization model or a 
spreadsheet. 
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2. Activity Models 

Activity analysis is also an important measure in fleet mix planning. It 
could help the decision maker determine how many vessels are required in a 
district to meet a certain level of demand. The activity model could be 
written entirely in Nexpert or could rely on Nexpert to call an external 
program. 

3. Performance Models 

The performance models used in this research do not evaluate use of 
other Coast Guard assets. Further research could include development of 
models for use by the Navy, Army or other branches within the Coast Guard. 

4. Expand to Other Aspects of the A-109 Process 

The system could be augmented with features that address the other 
phases and milestones of the A-109 process. Possible enhancements to the 
system include a more elaborate cost evaluation meeting the requirements of 
the lifecycle cost analysis of the A-109 Circular. Further, an important 
enhancement would be the development of reports with justification needed 
for certain milestones. 

D. SUMMARY 

7 

This research has built on previous fleet mix planning research. In 
particular, the efforts of the Coast Guard Patrol Boat Capability Replacement 
Branch [Ref. 8], the Coast Guard Research and Development Center [Ref. 13], 
and the Balance Sheet Approach to Fleet Mix Planning [Ref. 3] were used to 
design and develop a working prototype tool for fleet mix planning in the 
Coast Guard. Though the implementation of our design is partial, early 
feedback from the Coast Guard has been encouraging. The system 
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enhancements and additional research topics would add greatly to the 
capability of the system. The goal of the design team has been realized. We 
hope the project will continue, and that better fleet mix decisions will be 
possible as a result of using this tool. 



61 



LIST OF REFERENCES 



1. Coast Guard Overview 1989 - 1990, 200 Years of Service, 1990. 

2. U.S. Coast Guard, Candidate WPB Craft Study (Second Analysis), Office of 
Research and Development (G-D), U.S. Coast Guard Headquarters, Washington 
D.C., 1987. 

3. Bhargava, Hemant, Steven O. Kimbrough, and Clark W. Pritchett, A Balance Sheet 
Approach to Fleet Mix Planning, University of Pennsylvania, Department of Decision 
Sciences working paper, 1990. 

4. United States Coast Guard Memorandum G-OP/32, Mission Needs Statement for 
WPB Capability Replacement of 1 June 1983, Jul 1983. 

5. Emery, James C., Management Information Systems: The Critical Strategic Resource, 
Oxford University Press, 1987. 

6. Department of Defense Directive 5000.1, Policies Governing Major and Nonmajor 
Defense Acquisition Programs, July 1, 1990. (Draft Copy) 

7. Pritchett, Clark, Predicting Patrol Performance, paper presented at 56th MORS, 29 
June 1988. 

8. Pritchett, Clark W. and S. F. Roehrig, Search and Rescue Monte Carlo Simulation, 
Report No. CG-D-12-86, U.S. Coast Guard Research and Development Center, 
March 1985. 

9. Himes, Andrew and Craig Ragland, Inside SuperCard, Microsoft Press, Redmond, 
Washington, 1990. 

10. Department of Defense Directive 4245.7-M, Transition From Development To 
Production. ..Solving The Risk Equation, September 1985. 

11. Interview between Clark Pritchett, U.S. Coast Guard R&D Center, Groton, CT, and 
the authors, 4 December 1990. 

12. Trutna, Rick and Catherine Mone, ORACLE for Macintosh Reference .Version 1.2, 
Oracle Coporation 1990. 

13. Neuron Data Corportation, NEXPERT OBJECT: Database Inegration Guide Version 
2.0, Neuron Data 1991. 

14. Neuron Data Corportation, The NEXPERT HyperBridge: Version 2.0 User's 
Manual, Neuron Data 1990. 



62 



15. Schneiderman, Ben, Designing the User Interface: Stratgiesfor Effective Human- 
Computer Interaction, Addison-Wesley Publishing Company, 1987. 



63 



INITIAL DISTRIBUTION LIST 



No. Copies 



1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, Virginia 22304-6145 

2. Library, Code 52 2 

Naval Postgraduate School 

Monterey, California 93943-5100 

3. Professor Hemant K. Bhargava (Code AS/BH) 1 

Naval Postgraduate School 

Monterey, California 93943-5002 

4. Professor Gordon Bradley (Code OA/BZ) 1 

Naval Postgraduate School 

Monterey, California 93943-5002 

5. Professor Michael G. Sovereign (Code OR/SM) 1 

Naval Postgraduate School 

Monterey, California 93943-5002 

6. Commandant (G-AWP) 2 

U. S. Coast Guard 

2100 Second St. S.W. 

Washington, D.C. 20593 

7. Clark W. Pritchett 1 

U.S. Coast Guard Research and Development Center 

Avery Point, Groton, Connecticut 06340 

8. Capt. William G. Simpson 1 

Commandant (G-AWP) 

U. S. Coast Guard 
2100 Second St. S.W. 

Washington, D.C. 20593 



64 



9. Steven O. Kimbrough 1 

The Wharton School 

3620 Locust Walk # 1300 
Philadelphia, Pennsylvania 19104-6366 

10. Professor Keebam Kang, Code AS/KK 1 

Naval Postgraduate School 

Monterey, California 93943-5002 

11. LCDR Thomas J. Kaiser 1 

167 Centerview Drive 

Portsmouth, Rhode Island 02871 

12. LT Louis A. Cortez 1 

957 West Goodview Drive 

Virginia Beach, Virginia 23464 



65 



V 



Thesis 
C755737 
c. 1 



Cortez 

U.S. Coast 
fleet mix 



